NeverCast [Joshua Lloyd]

After some watching of mobs that do this, It seems to occur after they collide with a wall, can anyone verify? It seems like when they hit a wall for some reason they drop in to the ground on occasion to the block below them, causing glitchy appearance

On collision it should raytrace itself to one of the boxes of the mob, and then solve it's location on the face it hit, it should then child itself to that box with it's rotation point and offset set accordingly to it's collision point and travelling vector at the time of impact. That said the raytrace is probably not required as all the collisions in game use AABB anyway.

Edit: It already works on players so all this code is already implemented, It's probably just a pain to get it rendering correctly once the arrow becomes a child of the entities model, due to said scaling.

Each entity has it's own instance, id's are irrelevant. You can scale differently depending on the size of the slime, which is just a datavalue thing I believe anyway, as you can spawn really large slimes with plugins/mob spawners/mods/other spawny thingies.

I'm not quite sure how the arrows were attached, but you could probably glScale the inverse of the scale used on the rest of the mob when rendering the arrow. But as I'm not aware of how it was implemented I can't suggest anything, We'll just have to wait and see if Mojang comes up with something.

Probably because the arrow was attached to the model, @Meta.
But because some of the models are scaled, the arrow would also be scaled.

Oh thank goodness, as this caused massive issues with mods also, every single tile entity would randomly not have any information associated it, NPEs across the board. It seems this may have been the issue, and there I was looking at the mod apis for bugs, never thought it to be a vanilla issue.

Thanks again Jeb.

Now you're trolling, this issue is closed, and so is this conversation.

Then I guess the MobSpawner needs amending, this would all go in to the MC API imo.
If you go home, grab some sand, and put it on a fire, tell me if it burns. If it burns I'll eat my words, otherwise I stand by saying that sand doesn't burn as a block, and it shouldn't burn as an entity.

Why make an exception?
I think the title answers that for you, it's sand, sand isn't flammable. Walking Dead, Corpses and people are flammable, but not sand.

Edit: It's marked as resolved, DinnerBone approves that it's a bug, case closed I think.

Yes, me too. It's been a quirk I've noticed for a long time but never thought of actually reporting it.
Now that there is Mojira, I've actually been more aware of bugs in MC, such as last night when a player was floating above the bed.
But I'm no so good with the creating an issue and such 😛

Thanks Charlie.

^ Don't forget to back up your saves folder if you want to keep your worlds

He said to override the isBurning method in EntityFallingSand, That only affects Sand, not every block.
I don't see anywhere that implies that all blocks should not burn.

@Anon, Sand and Gravel never burn, we're talking about the Entities, not the items here. Sand and Gravel ( and any future falling blocks similar ) should not show fire as they do not burn. If it doesn't combust in Block form, it shouldn't show fire animation in entity form.

Woah, all the comments all at once.

Iron Golems have always been able to hold out roses, just check the wiki. In no way does this seem like a bug.

Thanks Jens,
You're wonderful!

Yes Enrique, I think you're right on there.
By removing the 'extra block's hitbox, and expanding the 'source block's hitbox to include both blocks, ( Top of the door, piston head etc ), it would certainly fix this issue.
That way the active block would be the one with the hit box and the other would be there for purely visual reasons.

Hitboxes I believe are typically floats from 0-1, 1 being a full block, I'm not certain if a hitbox can expand more than 1m-cube, but I don't see why not.

Duplicate bug of MC-119 perhaps.

Does this still happen with Smooth Lighting turned off?
Could be an AO bug.

I notice this with any moving entity in Multiplayer servers, from what I gather, sometimes the client gets confused about where the entity actually is, and because Minecraft's movement data is relative not absolute ( Unless teleporting or moving more than 4, i think it's 4; blocks in a single movement ). When this occurs, you can either try get the mob to move really fast, in the case of a player, tell them to run around and jump lots for your own sanity so they stop glitching in the ground, as for actual mobs. It's a bit more difficult to fix it, one solution is to walk away and come back, or to pick them up with a minecart.

I realise that there is no difference between multiplayer and the integrated single player now, but it does seem to occur more often in SMP, which I'm assuming is due to some sort of latency.

Solution?
Client assumes the mob is actually on top of the block using it's AABB, or the server periodically sends Teleport packets refreshing the client of the entities actual position. Maybe only within a few chunks of you do the entities have an update, this will reduce some of the bandwidth incurred by the extra packets.